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REMARKS 

Applicant amends claim 38 to add a period to the end of the claim. This 
period in no way alters the meaning of the claim and should be entered under 37 C.F.R. 
§1.1 16(b)(2). Applicant agrees with the Examiner's comment on page 2 of the outstanding 
Office Action that claims 16-28, 32-34, 36, and 38 are pending. 

35 U.S.C. § 103(a) Rejections 

The Examiner rejected claims 16-18, 21-25, 28, 32, 34, and 38 under 103(a) 
being unpatentable over Rune (U.S. Patent Publication no. 2004/0167988) in view of Jou, 
2005/0036489. Applicant respectfully disagrees. The currently pending independent claims 
are claims 16, 21, 22, and 32. 

Claim 16 is representative and is reproduced below. 

A method comprising: 

checking a destination address of a received packet; 

comparing the destination address of the packet with at least 
one predetermined multicast and/or broadcast address; 

preventing the transmission of the packet to a first device in 
response to the addresses matching; and 

forwarding the packet to at least the first device in response to 
the addresses not matching. 

The Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
titmsmtssioti of the packet to a first device in response to foe addresses matching; in 
response to the address not matching* However, Jcra teaches comparing the destination 



8 



S.N. 10/587,979 
Art Unit: 2476 

Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose this subject matter. 

The Examiner then points to Jou for alleged disclosure of this subject matter. 
However, Jou does not disclose this subject matter for at least the following reasons. 

Jou does not disclose the subject matter alleged by the Examiner: First Reason 

The instant application has a priority date of 6 February 2004 under, e.g., 
M.P.E.P. §201.13, 35 U.S.C. §119 and 37 C.F.R. §1.55. That is, the priority date of 6 
February 2004 is based on a Finnish application filed on that date, which later became an 
international (P.C.T) application filed on 4 February 2005. The international application 
entered national stage in the U.S. on 10 October 2006 as the instant application. Therefore, 
the priority date of the instant invention is 6 February 2004. 

Turning to Jou, the published application 2005/0036489 was filed on 10 
August 2004, after the priority date of 6 February 2004 of the instant application. Jou's 
published application claims priority from provisional application 60/495,186, a copy of 
which is enclosed herein as Appendix A. The Jou provisional application was filed on 15 
August 2003. Therefore, for material to be cited against the instant application, that material 
must exist prior to the priority date of the instant application of 6 February 2006. 

The Examiner cites to paragraph 29 of Jou's published application, which 
states the following: 

[0029] FIG. 5 illustrates the processing flow chart on receiving 
a broadcast frame. In step 500, a wireless transport device receives a broadcast 
frame. The wireless transport device will determine whether or not the DA 
filed is the same as the local MAC address of this device (510). If positive, the 
wireless transport device drops the frame because it is an echoed frame (step 
530). Otherwise, it uses Auxiliary Address to verify whether this frame is 
received through the correct neighbor, namely in step 520, to look up the route 
table. Subsequently, in step 540, the wireless transport device determines 
whether the TA address is the neighboring node the frame should come from. 
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If positive, then the wireless transport device relays the frame or performs 
other process (550), otherwise, drops the frame (step 530). 

The subject matter in this paragraph of Jou's published application does not appear in Jou's 
provisional application. In particular, the subject matter of "The wireless transport device 
will determine whether or not the DA [destination address] filed (sic?) is the same as the local 
MAC address of this device (510)" does not appear in Jou's provisional application. 
Therefore, this subject matter has the filing date (10 August 2004) of Jou's provisional 
application. The filing date (10 August 2004) of Jou's provisional application is after the 
priority date (6 February 2006) of the instant application, and therefore the cited subject 
matter in paragraph 29 of Jou's published application does not qualify as prior art under 35 
U.S.C. §102. 

Consequently, the sections cited by the Examiner of Jou's published 
application cannot be cited as prior art against the claims of the instant application. Because 
the Examiner admits that Rune does not disclose certain subject matter from the claims, and 
the subject matter supposedly disclosed in Jou's published application is not prior art against 
the independent claims, Applicant respectfully submits the 103(a) rejections against the 
independent claims must fail. 

Jou does not disclose the subject matter alleged by the Examiner: Second 
Reason 

Even if the cited sections of Jou's published application are prior art against 
the instant independent claims, Applicant respectfully submits that Jou's published 
application does not disclose the subject matter the Examiner asserts is disclosed by Jou's 
published application. For instance, the Examiner cites to paragraph 29 of Jou's published 
application (emphasis added): 

[0029] FIG. 5 illustrates the processing flow chart on receiving 
a broadcast frame. In step 500, a wireless transport device receives a broadcast 
frame. The wireless transport device will determine whether or not the DA 



10 



S.N. 10/587,979 
Art Unit: 2476 



filed (sic?) is the same as the local MAC address of this device (510) . If 
positive, the wireless transport device drops the frame because it is an 
echoed frame (step 530). Otherwise, it uses Auxiliary Address to verify 
whether this frame is received through the correct neighbor, namely in step 
520, to look up the route table. Subsequently, in step 540, the wireless 
transport device determines whether the TA address is the neighboring node 
the frame should come from. If positive, then the wireless transport device 
relays the frame or performs other process (550), otherwise, drops the frame 
(step 530). 

This section of Jou' s published application indicates that a determination is made of whether 
or not the DA (destination address) is the same as the local MAC (media access control) 
address of the device. It is known in the art that a MAC address is a unique identifier assigned 
to network interfaces for communications on the physical network segment. What the 
sentence "If positive, the wireless transport device drops the frame because it is an echoed 
frame (step 530)" appears to mean is that the current device previously transmitted the frame, 
and the frame is being echoed back to the device. Thus, the device put the MAC address of 
itself into the frame, and transmitted the frame. When the device receives a frame that has its 
MAC address, the device then determines the frame is an echoed frame and can be ignored. 
See also paragraph 22 of Jou's published application (emphasis added): 

[0022] Depending on the method in unicast routing path 
calculation, the forwarding table for unicast frames can be used as the table 
that is used to look up the incoming neighboring device for a broadcast frame 
originator (i.e. FIG. 2). In this case, there is no extra effort in generating the 
broadcast frame reduction table. The other method to reduce the resource 
spending on broadcast frames is to reduce the processing effort for echoed 
broadcast frames. For example, a device X either sends or relays a broadcast 
frame to its neighbors Nl and N2. When Nl and N2 relay the frame, most 
likely device X will receive both the frames. Using the method mentioned 
earlier can cause the frames being dropped eventually. However, a table 
lookup for each frame will be needed for device X. To relieve the processing 
load, Nl and N2 can both add the address of X inside the frame. When X 
receives a broadcast frame, it can check whether the frame is echoed from 
itself. If so, the frame can be dropped immediately without processing. 
Therefore, to filter out echo frames, broadcast frames have to carry the 
address information of previous hop in the transmitted frame. This can be 
achieved by using an unused field in the 802.1 1 MAC header. In broadcasting, 
the Address 3 (DA, destination address) of FIG. 3 is not used. The "previous 
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hop" information is carried in the location the Address 3 (DA, destination 
address). 

Moreover, the MAC address of the device is not a "broadcast address", as this 
is the address of the device itself: "The wireless transport device will determine whether or 
not the DA filed (sic?^ is the same as the local MAC address of this device (510)." 
Paragraph 29 of Jou's published application. See also paragraph 22 of Jou's published 
application: "Therefore, to filter out echo frames, broadcast frames have to carry the address 
information of [the] previous hop in the transmitted frame." Another device receiving the 
frame with the MAC address of the previous hop is not going to determine the MAC address 
is a broadcast address or use the MAC address as a broadcast. Furthermore, it is known that a 
broadcast address in MAC (e.g., 802.1 1) is all ones, e.g., FFFFFFFF for 32 bits in 
hexadecimal. See paragraph 27 of Jou, or http://en.wikipedia.org/wiki/MAC_address 
("Packets sent to the broadcast address, all one bits, are received by all stations on a local area 
network. In hexadecimal the broadcast address would be FF:FF:FF:FF:FF:FF"). This means 
that the MAC address of a device will not be the same as the broadcast address. 

Thus, Jou's published application does not disclose at least the subject matter 
of "comparing the destination address of the packet with at least one predetermined multicast 
and/or broadcast address", "preventing the transmission of the packet to a first device in 
response to the addresses matching", "forwarding the packet to at least the first device in 
response to the addresses not matching", as recited in claim 16 and generally in the other 
independent claims. 

Because the Examiner admits that Rune does not disclose certain subject 
matter in the claims, and because Jou's published application does not disclose this certain 
subject matter, Applicant respectfully submits the 103(a) rejections against the independent 
claims must fail. 
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Rune 

Regarding Rune, Applicant respectfully submits that one skilled in the art 
would not combine Rune and Jou's published application in the manner suggested by the 
Examiner. What Rune states regarding broadcast types is the following (emphasis added) 

[0123] FIGS. 10-15 illustrate the coverage areas of the different 
broadcast types. The NAPSA broadcast type, as the name implies, is used to 
broadcast packets to a single NAPSA. This is illustrated in FIG. 10 (which is 
similar to FIG. 8), where each isolated gray area 1000-1008 represents a 
different NAPSA broadcast area. A NAPSA broadcast packet is not allowed 
to leave its broadcast area. Thus, NAPSA broadcast packets are not 
forwarded to the LAN and are not allowed to cross a NAPSA border. 

[0124] The scatternet broadcast type, as the name implies, is 
used to broadcast packets within the scatternet. This arrangement is illustrated 
in FIG. 11, where each contiguous gray area 1 1004 106 represents different 
broadcast areas for a scatternet broadcast packet. Such broadcast packets are 
not forwarded to the LAN. When more than one AD exists in a scatternet, 
the scatternet broadcast packets carrying higher layer protocol packets, i.e. 
packets from protocol layers above the NAL, e.g. IP, are not allowed to cross 
an AD border. These packets are consequently limited to a part of the 
scatternet belonging to the same AD. Scatternet broadcast packets that are not 
carrying packets from higher layer protocols, such as NAL control packets, 
however, are allowed to cross AD borders and may therefore still be broadcast 
in the whole scatternet. A NAL control packet does not encapsulate data from 
a higher protocol layer and is only used to transfer signaling and control 
information between NAL entities in different Bluetooth nodes. This 
arrangement is illustrated in FIG. 12, where each contiguous gray area 1200 
and 1202 represents the broadcast area of an NAL control packet. 

[0125] The AD broadcast type covers the LAN and any 
attached scatternets that are associated with the same AD as the LAN. These 
broadcast packets are forwarded by NAPs from/to the LAN to/from the 
scatternet, but the NAPSA borders in the scatternet are respected. This 
arrangement is illustrated in FIG. 13, where each contiguous gray area 1300- 
1304 represents the broadcast area of an AD broadcast packet. An AD 
broadcast packet is used to reach all the nodes in the AD (including the nodes 
on the LAN). All broadcast packets that are forwarded from the LAN to the 
scatternet are sent using the AD broadcast type. 
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[0126] The scatternet-AD broadcast type is a special broadcast 
type used only for route requests. This broadcast type is, as the name implies, a 
combination of the scatternet broadcast type and the AD broadcast type. The 
scatternet-AD broadcast packets are distributed through the entire scatternet 
without respecting the NAPSA borders, as well as the entire AD via the NAPs. 
However, the NAPSA borders are respected after a scatternet-AD broadcast 
packet re-enters the scatternet via a NAP. 

Thus, in Rune, the NAPSA broadcast packets are not forward to a scatternet, and the 
scatternet broadcast packets are not forwarded to the LAN. However, these packets are not 
forwarded based on their broadcast type, which is defined by an indicator in a NAL (network 
adaptive layer) header (emphasis added): 

[0122] In addition to the routing protocol discussed above, the 
NAL also has a broadcast mechanism. (Note that broadcasting on the LAN is 
inherent in the shared medium and no "broadcast" mechanism is needed.) In 
accordance with embodiments of the invention, the NAL includes four 
different types of broadcasts: NAPSA broadcast, scatternet broadcast, AD 
broadcast, and scatternet-AD broadcast. The differences between broadcast 
types lie in the scope of the distribution and how the NAPs and other nodes at 
the NAPSA borders treat the different broadcast packets. Note that the 
broadcast type is defined by an indicator in the NAL header. In that sense, 
these different broadcast types can only exist in the scatternet. On the other 
hand, an Ethernet broadcast packet (originated on the LAN) that is forwarded 
from the LAN to the scatternet becomes an AD broadcast packet when it is 
forwarded into the scatternet. The broadcast type may be indicated in the NAL 
header, for example, with a two-bit indicator, as indicated in Table 2. 

Thus, the broadcast type is defined in Rune by an indicator in the NAL header. 

It is clear that filtering of broadcast packets in Rune is performed without 
examination of destination addresses for packets (emphasis added): 

[0196] The second main component of the invention is the 
packet filtering mechanism. As already mentioned, a NAP does not 
indiscriminately forward packets. Instead, it uses the packet filtering 
mechanisms (see FIG. 9) to reduce the number of unnecessarily forwarded 
packets. For example, forwarding is unnecessary when both the source and the 
destination node are located on the same side of the NAP. Furthermore, NAL 
broadcast packets of the NAPSA broadcast type and the scatternet broadcast 
type are always blocked by the packet filtering mechanisms. Only those 
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packets that pass the packet filtering mechanisms are forwarded to the 
scatternet The generated useless traffic is a waste of resources, especially so 
in the scatternet where radio resources and processing resources are scarce. 
Furthermore, this could lead to the scatternet being flooded by traffic from the 
LAN with its shared medium and much higher capacity. Therefore, a packet 
filtering mechanism is needed in order to limit the forwarding of unnecessary 
traffic. The packet filtering is based on the destination address and the NAL 
packet type. Filtering may also be based on higher layer protocols. 

[0197] The NAL packet type filtering in the NAP is performed 
in the packet type filtering function 912, which is present only on the 
scatternet side of the NAP. The NAL packet type filtering , in some 
embodiments of the invention, is very simple: all NAPSA broadcast type and 
scatternet broadcast type packets are passed by the packet type filtering 
function 912 to the NAP-IPEU while all other packet types are passed to the 
address filtering function 914. 

Thus, packets having the NAPSA broadcast and scatternet broadcast types are filtered, and all 
other packet types are passed to an address filtering function, for forwarding to the correct 
address. See also, e.g., paragraphs [0222], [0224], [0237] of Rune. 

As is noted in paragraphs [0125] and [0197] from Rune above, packets having 
the AD broadcast type are forwarded, as are packets having the scatternet- AD broadcast type 
(see paragraphs [0126] and [0197]). 

Regarding multicast addresses, these appear to be related to route entries. See, 
e.g., the following: 

[0173] When (and if) the NAP-B of a NAP receives an 
encapsulated non-ARP-route-request (via the NAP-PFL), the NAP processes 
the non-ARP-route-request just like any node would process a received non- 
ARP-route-request. Thus, the NAP forwards the non-ARP-route-request into 
the scatternet, unless it already has a route to the destination node, or unless 
the NAP itself is the destination node. In the latter case, the NAP can 
immediately return an encapsulated non-ARP-route-reply. Then the next hop 
node in the route entry for the source node is indicated as "another NAP." This 
indication may be just a general indication, or it may be a specific indication 
that includes a NAP multicast address or the specific source MAC address of 
the Ethernet packet that carried the received encapsulated ARP-route-request. 
The choice between general indication, NAP multicast address or source MAC 
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address depends on whether broadcast packets, multicast packets or unicast 
packets are used to carry a corresponding encapsulated ARP-route-reply. 

See also paragraphs [0156], [0186], and [0187] of Rune. There are additional references to 
"multicast" in Rune, but none of these references relate to the subject matter of "comparing 
the destination address of the packet with at least one predetermined multicast and/or 
broadcast address" and "preventing the transmission of the packet to a first device in response 
to the addresses matching" as recited in amended claim 16. 

Applicant respectfully submit that this is further evidence that one skilled in 
the art would not combine Rune and Jou' s published application in the manner suggested by 
the Examiner, as Rune is examining packet types while Jou's published application is looking 
for a MAC address in a received frame of a device that previously sent the frame. These do 
not appear reconcilable. 

For at least this reason, the rejections of the independent claims should be 

withdrawn. 

Dependent claims 

The dependent claims are also patentable over the combination of Rune and 
O'Neill for at least the reasons given above. 

Additional 35 U.S.C. § 103(a) Rejections 

The Examiner rejected other dependent claims. For instance, the Examiner 
stated the following: 
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4. Claims 19,20,26,27 and 33 rejected under 35 U.S.C 103(a) as being unpatentable over 
Rime m applied to claims 1648, 21-25* 28, 32, 34, and 38 above and. further in view ofVasisht 
(US 2004/0133689). 

Outstanding Office Action, page 10. The Examiner also stated the following: 

7. Claim 36 is rejected under 35 U.S.C. 103(a) m being unpatortable over Rum m applied 
to claims 16,1.821,22,25,28331,3234 and 35 above, and farther in view of Tung (US 
2006/0136562 Al) (herein afar Tung). 

Outstanding Office Action, page 13. 

It is believed these two sets of rejections should use both Rune and Jou's 
published application in addition to Vasisht and Tung. 

Regardless, because independent claims 16, 22, and 32 are patentable, the 
dependent claims are patentable for at least the reasons given above. 

Conclusion 

Based on the foregoing arguments, it should be apparent that the pending 
claims are thus allowable over the reference(s) cited by the Examiner, and the Examiner is 
respectfully requested to reconsider and remove the rejections. The Examiner is invited to 
call the undersigned attorney for any issues. 
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Respectfully submitted: 



Robert J. Mauri Date 
Reg. No.: 41,180 



Customer No.: 10,948 

HARRINGTON & SMITH, Attorneys at Law, LLC 

4 Research Drive 

Shelton, CT 06484-6212 

Telephone: (203)925-9400 

Facsimile: (203)944-0245 

email: rmauri@hspatent.com 
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Appendix A 

Jou's Provisional Application 60/495,186, filed on 15 August 2003 
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Claims 

The embodiments of the invention claim the following: 

1 . The method for a device to calculate a table that each entry contains the 
neighboring device from which a broadcast frame originated from a particular 
device can be received. 

2. The method according to claim 1, further comprising the steps of: 

for broadcast frames originated from the particular device, only the ones relayed 
through the listed neighboring device can be accepted. Broadcast frames coming 
through incorrect neighboring device are duplicates and should be ignored or 
dropped. 

3. The method according to claim 1, further comprising the steps of: 

carrying the name or address of the originator wireless transport device as part of 
the broadcast frames to facilitate the filtering on broadcast frames. 

4. The method for a transport device when relays a broadcast frame, to add the 
address information of the previous hop from where the frame comes into the 
transmitted frame. 

5. The method according to claim 4, wherein: 

When a wireless transport device receives a broadcast frame whose "previous 
hop" field contains its own address, the device can drop the frame without any 
further processing. 

For example, a device X either sends or relays a broadcast frame to its neighbors 
Nl and N2. When Nl and N2 relay the frame, they both add X in the "previous 
hop" field of the frame. Most likely device X will receive both these relayed 
frames from Nl and N2. With its address contained in the frame, device X can 
immediately realized it should drop the frames without processing. 
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6. The method to embed the announcement information of a newly associated 
wireless client of a transport device into a broadcast frame the client generates if it 
is the first frame from the client system into the network. 

7. The election among the multiple edge devices connecting the wireless network to 
a wired network to enable only one edge device to relay broadcast traffic across 
the wired and wireless network. 

Description 

THE FIELD OF THE INVENTION 

The present invention relates to communications systems that comprise wireless networks. 
The invention is particularly concerned with reducing transmission information frames on 
the wireless networks and across the wireless and wired border line and is most useful in 
networks requiring multi-hop wireless communication. 

BACKGROUND OF THE INVENTION 

A wireless transport network is a network comprises a plurality of wirelessly connected 
devices that are responsible for relaying traffic for associated mobile clients. An example 
of a wireless transport network is a plurality of IEEE 802.1 1 capable devices that provide 
transport service for IEEE 802.1 1 or Bluetooth capable clients such as laptop computers, 
PDA (personal digital assistant), and the like. The said network can further comprise one 
or more connections to a wired network through one or multiple edge devices. The edge 
devices are equipped and capable of both wireless and wired communication. An 
example is shown in FIG. 1 . 

In a wireless transport network, efficient reduction of unnecessary broadcast traffic is 
critical. The transmission medium (the air) by nature is shared, therefore broadcast is a 
convenient way of communication in wireless networks for there is no need to transmit 
multiple times for a multi-destined frame. Once an originator broadcasts a frame to all its 
neighboring devices, all, or some, of its neighboring devices will have to relay the frame 
for other remote devices. For any device that is a neighbor of multiple devices that are 
responsible for relaying broadcast frames, it receives multiple copies of the same frame. 
One simple example is once a device sends out a broadcast frame, it immediately 
receives multiple copies of the exact frame if there are multiple neighboring devices 
perform relay function for the frame. Unless a filtering method is implemented on the 
devices, in the worst case one single broadcast frame may be duplicated in an exponential 
growth fashion and saturate the network and waste device processing time. In the worst 
case, these frames may loop around the network until the end of their lives. 

Reducing the unnecessary broadcast frames can prevent frame looping, reduce total 
traffic amount hence preserve network bandwidth, and save device processing effort. 
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PRIOR ART 

Prior art techniques in saving bandwidth on wireless network include software algorithms 
to select relay nodes for broadcast traffic, and maintaining sequence numbers of frames 
originated from each device to discard duplicates. 

US Patent number 5,570,366 describes a method to filter frames from a wired network to 
a wireless access point via configured protocol parameters. 

Present invention provides more efficient methods to filter unnecessary broadcast traffic 
and the techniques are more suitable to be implemented in firmware or hardware to 
enhance forwarding throughput. 

US Patent number 6,549,786 claims the mechanism to set up a plurality of wireless nodes 
and a plurality of wired- wireless edge access points to form a local area network. The 
internetworking edge access points are used to relay traffic for wireless nodes unless the 
source and destination pair can communicate with each other directly. The wireless nodes 
actively select which access point it should be associated with, and determines whether it 
needs an AP's help to send messages. This addresses only the client- access point 
architecture and covers only basic connectivity issues. 

SUMMARY OF THE INVENTION 

Each wireless transport device calculates a table that each entry (FIG. 2) contains the 
neighboring device from which a broadcast frame originated from a particular device can 
be received. For broadcast frames originated from a particular device, only the frames 
relayed through the listed neighboring device can be accepted. Broadcast frames coming 
through incorrect neighboring device are duplicates and should be ignored. To facilitate 
the above filtering function, the broadcast frames have to carry the name or address of the 
originator wireless transport device. Note the frame may have come from a client of the 
wireless transport device therefore it is not the real source of the frame. 

To filter out echo frames, broadcast frames have to carry the address information of 
previous hop in the transmitted frame so once the previous hop receives the frames, it can 
ignore these echo frames without further processing. For example, a device X either 
sends or relays a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, they both add X in the "previous hop" field of the frame. Most likely device X 
will receive both these relayed frames from Nl and N2. With its address contained in the 
frame, device X can immediately realize it should drop the frames without processing. 

Client membership announcement of a newly associated wireless client of a transport 
device is embedded into a broadcast frame the client generates, if it is the first frame from 
the client system. If the client is running common network layer protocols, the first frame 
is likely a broadcast frame. For example, in an IP network, the first frame from a newly 
booted up station usually is a broadcast frame containing either DHCP request or an ARP 
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request. The client membership announcement is piggybacked into the broadcast frame 
which saves the introduction of two different frames. 

In case there are more than one edge device connecting the wireless network to a wired 
network, our invention is the election among the edge devices to enable only one edge 
device to relay broadcast traffic across the wired and wireless network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates an example of a wireless transport network. 
FIG. 2 is an example of a broadcast receiving neighbor table. 
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